This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
In recent years, mobile broadcast solutions have been standardized by different organizations, such as the 3rd Generation Partnership Project (3GPP) MBMS service. MBMS is a broadcasting service that can be offered via existing GSM and UMTS cellular networks. 3GPP MBMS enables the resource-efficient delivery of popular multimedia content to the mobile users. A MBMS client can receive content via download delivery, streaming delivery and a combination of streaming delivery and download delivery.
MBMS is a feature described in 3GPP Release 6. However, MBMS may be deployed by operators in only a few areas where it is cost efficient to have broadcast/multicast distribution of popular content. When MBMS subscribers move to areas where there is no MBMS coverage, the operator may distribute the MBMS content in unicast mode. In such a use case, application/transport layer signaling is required in order to ensure the seamless handover between broadcast/multicast mode reception and unicast mode reception of MBMS content.
One of the objectives of a 3GPP SA4 Release 7 work item on MBMS user service extensions is to specify the application/transport layer signaling needed for MBMS content distribution in unicast mode (over streaming and interactive bearers). Another objective is to specify optimization techniques for MBMS content delivery.
Table 1 below shows the current working assumptions in 3GPP SA4 for the mapping between protocols to be used in broadcast/multicast and unicast modes.
TABLE 1Streaming +Download onlyStreaming onlyDownloadUse CaseUse CaseUse CaseMBMSFLUTE/UDPMBMS StreamingMBMS StreamingContentFrameworkFrameworkDistribution inRTP/UDP forRTP/UDP for mediaBroadeast/media transporttransportMulticast ModeRTP/UDP forRTP/UDP for FECFEC transporttransport +FLUTE/UDP forfile downloadMBMSOMA-PUSHPSSePSSeContentOTA-WSPRTSP for sessionRTSP for sessionDistribution inOTA-HTTPcontrolcontrolUnicast ModeRTP/UDP forRTP for mediamedia transporttransportFLUTE/UDP forfile download inthe same RTSPsession
The File Delivery over Unidirectional Transport (FLUTE) protocol is discussed in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 3926, available at www.ietf.org/rfc/rfc3926.txt (incorporated herein by reference). The User Datagram Protocol (UDP) is discussed in IETF RFC 768, available at www.ietf.org/rfc/rfc0768.txt (incorporated herein by reference). RTP, a transport protocol for real-time applications, is discussed in IETF RFC 3550, available at www.ietf.org/rfc/rfc3550.txt (incorporated herein by reference). The Wireless Session Protocol (WSP) is discussed in the Open Mobile Alliance WAP-230-WSP, available at www1.wapforum.org/tech/documents/WAP-230-WSP-20010705-a.pdf (incorporated herein by reference). The Real Time Streaming Protocol (RTSP) is discussed in IETF RFC 2326, available at www.ietf.org/rfc/rfc2326.txt (incorporated herein by reference).
3GPP Packet-switched Streaming Service (PSS) is the 3GPP's solution for enabling packet-switched streaming in mobile devices. PSS defines protocols and media codecs for enabling the streaming service for mobile devices. PSS is based on RTSP for session setup and control. 3GPP Packet-switched Streaming Service enhancements (PSSe) are currently being defined in 3GPP. The goal of these enhancements is to define extensions to 3GPP PSS Release No. 6 to optimize the streaming service. A general description of PSS can be found in 3GPP TS 26.233 V6.0.0 (2004-09): Transparent end-to-end packet switched streaming service (PSS); General description (Release 6), available at www.3gpp.org/ftp/Specs/archive/26_series/26.233/ (incorporated herein by reference).
For the “download only” use case, the MBMS handover mechanism is currently not fully specified.
An Open Mobile Alliance (OMA)-PUSH session is one option for implementing such a handover but suffers from a number of drawbacks. The OMA-PUSH system is generally as follows according to the proposal in 3GPP TSG-SA4 #41 Tdoc S4-060662. In this system, if a MBMS user equipment (UE) is out of its home network, and if an attribute providing an access address, for example as an unicastAccessURI, is available in the deliver method description, then the MBMS UE registers its MBMS Download Services with the BM-SC. The unicast service delivery registration request includes an identification of the MBMS user service, for example as a serviceId of the MBMS user service and an identification of the user device, for example as the Mobile Station Integrated Services Digital Network (MSISDN) of the MBMS UE.
The MBMS UE makes a unicast service delivery registration request using the HTTP request method GET. HTTP is discussed in detail in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 2616 (June 1999): “Hypertext Transfer Protocol—HTTP/1.1”] (available at www.ietf.org/rfc/rfc2616.txt and incorporated herein by reference). The serviceId and the MSISDN of the MBMS UE are encoded into the URI query part, which is discussed in detail in IETF STD 0066/RFC 3986 (January 2005): “Uniform Resource Identifier (URI)” (available at www.ietf.org/rfc/rfc3986.txt and incorporated herein by reference incorporated herein by reference) as defined below and included in the HTTP GET request. GET/unicastReg?serviceId=urn:3gpp:0010120123hotdog&MSISDN=436642012345 HTTP/1.1
Host: bmsc.example.com
A MBMS Download Delivery Session may contain one or more files. The files are described in the FLUTE File Delivery Table (FDT). If a MBMS Download Delivery Method contains more than one file, then Multipart MIME, as defined in IETF RFC 2557 (March 1999): “MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)”, J. Palme, A. Hopmann, N. Shelness. (available at www.ietf.org/rfc/rfc3986.txt, incorporated herein by reference) is used to encapsulate the files into an aggregate service announcement document.
MBMS download over HTTP push bearers are formatted according to the OMA Push Over-the-Air (OTA) specification, as discussed in OMA Push OTA Protocol (25 Apr. 2001): WAP-235-PushOTA-20010425-a, available at www.openmobilealliance.org/tech/affiliates/wap/wap-235-pushota-20010425-a.pdf (incorporated herein by reference). OTA-HTTP is used over the HTTP push bearer. Application port addressing is used as specified in the OMA Push OTA Protocol. The application ID to be used is as allocated by the OMA Naming Authority (OMNA), as discussed in OMA OMNA Registered PUSH Application ID list www.openmobilealliance.org/tech/omna/omna-push-app-id.htm (incorporated herein by reference). The Content-Encoding header is included if the GZip compression utility is used.
The OMA-PUSH approach suffers from a number of drawbacks. For example, in this arrangement, the broadcast-multicast service center (BM-SC) does not have any information on the state of the MBMS client, i.e., the BM-SC has no idea of which objects, source blocks or symbols are yet to be delivered to the MBMS client via OTA-HTTP. The behavior of the BM-SC, after receiving the above-referenced unicast registration request, is not clear. However, the BM-SC can behave in any one of two ways. If a FLUTE session involves multiple objects of various sizes, then the BM-SC has to transmit all objects of the FLUTE session via the OTA-HTTP session, including the objects that the client had already received in the FLUTE session. This constitutes a substantial waste of resources. Alternatively, after receiving the above mentioned registration request, the BM-SC may send only the remaining objects via OTA-HTTP, which case the client has some ‘holes’ in the received data. In this scenario, the client has no data from the point when it stopped receiving FLUTE transmission and the point when the BM-SC starts sending the data via OTA-HTTP.
Additionally, at the end of an OTA-HTTP session, the client still has to initiate another HTTP session for the point to point (PtP) repair of the incomplete objects/source blocks. Although the signaling overhead can be reduced if the two HTTP sessions can be combined into one, one HTTP session is initiated by the BM-SC, while the other HTTP session is initiated by the client in these situations.
In the event that the file delivery table (FDT) is dynamic, then the BM-SC server may perform an OMA-PUSH operation to the client whenever there is an updated FDT. In this case, the client does not need do any polling for the FDT updates. However, the above-referenced drawbacks still exist.
Another option for implementing a MBMS handover during download delivery involves using FLUTE/UDP over a unicast system. However this method required unnecessary overhead for the inclusion of FLUTE headers and forward error correction (FEC) repair symbols. In particular, both FLUTE headers and FEC repair symbols are unnecessary for point-to-point delivery. Additionally, for FLUTE/UDP transport, a new RTSP session must also be established.
In addition to the above, the PtP repair request/response mechanism specified in MBMS TS 26.346 v.7.2.0 can also be extended for the MBMS handover use case under a few special circumstances. When a MBMS client moves from an MBMS-covered area into MBMS-outage area, it can trigger the PtP file repair mechanism. The client then attempts to perform FEC decoding of all source blocks of all objects received to that point, determine the number/identity of the missing symbols, and send an HTTP GET request to the repair server by including all required details (e.g., file URI, Source Block Number (SBN), number of missing symbols, Encoding Symbol IDs (ESI) of missing symbols etc). If the client had already received the FDT, and if the FDT remains static for the rest of the FLUTE session, then it knows which file URIs/objects to expect in the remainder of the FLUTE session. The client can then request the repair server for the remaining source blocks in the current object and the remaining objects in the current session. Thus, the MBMS client can reuse the PtP repair request mechanism for the MBMS handover use case also. Unfortunately, the FDTs are very likely to be dynamic, i.e., there may be new instances of FDTs transferred in the same FLUTE session. Therefore, the client cannot assume that the FDTs are static, since FLUTE explicitly allows FDTs to be dynamic, and it allows new instances of FDTs to be delivered in-band of the FLUTE session. Therefore, the PtP repair request mechanism cannot always be overloaded to cover the MBMS handover use case.
It would therefore be desirable to provide a solution that can be used for both static and dynamic FDTs but does not use excessive overhead.